Optimizing client code through automated server specialization

ABSTRACT

Improved end-to-end server-client communication is achieved, wherein a thin client requests services from a server using a condensed optimized protocol. A mediator is provided on the server, which translates encoded messages from the client into standard web service request formats. Results are re-encoded at the server and returned to the client. A code generator is provided to automatically create optimized and specialized client and server code using templates, in which the code is optimized according to the characteristics of the client and the specified services. Grouped messages are supported. Bandwidth consumption is reduced by the technique, which increases the performance of resource-constrained clients, such as small wireless devices.

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] This invention relates to improvements in end-to-endcommunication between a client and a server. More particularly, thisinvention relates to apparatus and methods for minimizing the resourcesused by a resource-constrained client, when accessing services providedby a server.

[0003] 2. Description of the Related Art

[0004] The meanings of acronyms and certain terminology used herein aregiven in Table 1. The terms Sun, Sun Microsystems, the Sun logo, Java,J2EE, J2ME, and J2SE are trademarks or registered trademarks of SunMicrosystems, Inc., in the United States of America and other countries.All other company and product names may be trademarks of theirrespective companies. TABLE 1 API Application Programming Interface HTTPHypertext transfer protocol J2EE Java 2 Enterprise Edition J2ME Java 2Micro Edition J2SE Java 2 Standard Edition MIDP Mobile informationdevice profile SOAP Simple Object Access Protocol WSDL Web ServiceDescription Language XML Extended Markup Language

[0005] When developing end-to-end applications for thin clients, such asmobile information devices, it is important that the client code forcommunicating with a server be as compact and efficient as possible, andthat traffic between the client and server be minimized when requestingservices or resources of the server. This is desirable, because theclient's resources are generally limited. Some clients have small memorycapacity and limited graphics capabilities. Other clients may need tominimize computation in order to avoid depleting battery power, or toimprove the responsiveness of an application. Furthermore, in thecurrent state of the art, network bandwidth limitations and latency canseverely limit the utility of thin clients.

[0006] J2EE and J2ME are widely used platform-independent technologies,which are used respectively for multi-tier enterprise applications andlow-end clients, such as mobile information devices, smart cards, andmobile telephones. The two technologies are not well integrated, and itis not convenient or practical for a J2ME client to directly access J2EEservices on a server. Known solutions designed for J2SE/J2EE integrationdo not scale down to the low processing power and network bandwidth ofJ2ME devices. As a result, developers are often compelled to spend agreat deal of engineering effort developing and debugging protocols forwireless communication.

[0007] One widely used protocol for accessing remote services is SOAP,which specifies how to encode and transmit method invocations andresponses using HTTP and XML. SOAP is commonly used in conjunction withWSDL, a language for declaring web services. J2ME clients are currentlyable to access web services using SOAP in several ways.

[0008] An extensible open-source API, kSOAP, available from Enhydra.org,is usable by a MIDP application for accessing a subset of SOAP services.This is a solution for MIDlets that need to communicate directly withthe server, or require flexibility. However, its memory footprint of 34Kbytes is currently too large for most MIDP devices.

[0009] Another API, kXML-RPC, is an open-source J2ME implementation ofthe protocol XML-RPC, available from Enhydra.org. This API is used forcross-platform remote procedure calls. XML-RPC is similar to SOAP, butis a more concise protocol. Less network bandwidth and processing powerare required to transport and parse messages. XML-RPC is less generic,and less widely supported than SOAP.

[0010] A distributed objects framework, YoCOA, is available fromYospace, 7, The Courtyard High Street, Staines, Middlesex, TW18 4DR, UK.YoCOA is a proprietary set of J2ME and J2EE tools and libraries forfacilitating end-to-end development. YoCOA provides remote procedurecalls to appropriately enabled J2EE services.

[0011] The software product Macrospace Connect, available fromMacrospace Ltd., 64 Knightsbridge, London, SW1X 7JF, UK, is anotherproprietary set of tools and libraries for facilitating end-to-enddevelopment.

[0012] Merely customizing a development tool to work optimally with SOAPand WSDL is not a good general solution for end-to-end communication, asthere are many existing server configurations in which the servicesprovided are neither expressed in WSDL nor accessed by SOAP.

[0013] Conventionally, optimization of the client code is accomplishedby manual code adjustment. This technique is cumbersome and laborintensive. Many different optimizations may be required for use withdifferent mobile information devices. Reliance on manual optimizationcan compel an application developer to dedicate expensive staff to thetask of accommodating new models and types of mobile information device.Thus, improving manual optimization techniques would seem to be anunpromising approach.

[0014] It is known to restrict access to software by a client by variouscode obfuscation techniques in order to prevent reverse-engineering ofsoftware, when using languages such as Java, which was designed to becompiled into a platform independent bytecode format. However, thesetechniques are of limited utility in minimizing an application's codesize.

SUMMARY OF THE INVENTION

[0015] According to some aspects of the invention, MIDP devicesemploying J2ME technology are enabled to conveniently and efficientlyaccess J2EE services that are provided over a data network, such as theInternet. The approach taken is to use as thin a client as possible,diverting as much processing as possible to the server and as much codedevelopment as possible to an automated tool.

[0016] In some aspects of the present invention the problem of clientcode optimization is solved by a technique, wherein a developer preparesan application for a resource-constrained client, such as a mobileinformation device, in which he “specifies services to be exported tothe client from server-side providers. A development tool incorporatinga template-driven code generator is invoked to automatically createspecialized client and server code, optimized for the specifiedservices. Use of an optimized protocol allows client code to beminimized through elimination of redundant code, and by using codeoptimizations that can be automatically selected by the code generator.The server code consists of a mediator that acts as a gateway betweenthe client and providers of the specified services, translating theoptimized protocol into a standard protocol that is expected by theproviders. The server-side providers thus see a conventional client, andneed not modify their standard procedures in any way in order to receiverequests from such low-end clients.

[0017] In some embodiments, the code generator is aware of thecharacteristics of the client, which knowledge is exploited for evengreater code optimization. For example, the code generator may alsoselect from among different implementations of a method in order toproduce a minimal code size. The results are superior to those thatcould be obtained by an optimizing compiler or code obfuscation engine.

[0018] An advantage of some aspects of the present invention isminimization of the computational load on the client by automaticallyand optimally distributing the computation between the client and theserver.

[0019] A further advantage of some aspects of the present invention isthe reduction of required network bandwidth, by providing a speciallyadapted, concise low-noise protocol to be used between the client andthe mediator. The mediator retains the ability to communicate with theservice endpoint using a conventional protocol.

[0020] Still another advantage of some aspects of the present inventionis enhanced system performance and reduced client code footprint, whencompared with conventional techniques such as code obfuscation.

[0021] The invention provides a method of communication between a clientoperating in a first platform-independent environment to a serveroperating in a second platform-independent environment in order toobtain a service for the client via the server, which is carried out bycompiling a program for the client from platform-independent sourcecode, using the program to generate a request for the service by theclient, encoding the request at the client according to a first formatto define an encoded message, and transmitting the encoded message to amediator. The method is further carried out at the mediator byre-encoding the encoded message into a second format, wherein the sizeof the re-encoded message exceeds the size of the encoded message, andtransmitting the re-encoded message to a provider of the service.

[0022] According an aspect of the method, the program has only theminimum code that is required to produce the first format.

[0023] In still another aspect of the method re-encoding the encodedmessage is performed by decoding the encoded message, and re-encodingthe decoded message into the second format.

[0024] According to an additional aspect of the method, the requestincludes a plurality of requests that are assembled into an encodedmessage group in the encoded message.

[0025] One aspect of the method includes delaying performance ofencoding the request for a latency interval to await pendency ofadditional ones of the plurality of requests.

[0026] According to a further aspect of the method, the plurality ofrequests are asynchronously initiated.

[0027] According to another aspect of the method, the second format isSOAP.

[0028] The invention provides a method of establishing access by aclient to predetermined server-side services, which is carried out byinstalling proxy code in the client to provide an interface with anapplication program executing therein, wherein requests for theserver-side services are generated by the application program, and theproxy code is adapted to reformulate the requests as first messagesaccording to a first protocol. The method is further carried out byexecuting a mediator program in a computing device external to theclient, wherein the mediator program accepts input from the clientaccording to the first protocol, and is adapted to re-formulate thefirst messages as second messages according to a second protocol. Thecomputing device is capable of communicating the second messages to aprovider of the server-side services.

[0029] According to an aspect of the method, the first messages aresmaller than corresponding second messages.

[0030] According to still another aspect of the method, the firstmessages each comprise a plurality of requests.

[0031] In an additional aspect of the method, installing proxy codeincludes automatically generating the proxy code, substantially withouthuman intervention.

[0032] In another aspect of the method, generating the proxy code isperformed according to a predefined template.

[0033] In one aspect of the method, executing the mediator programincludes automatically generating the mediator program, substantiallywithout human intervention.

[0034] In another aspect of the method, generating the mediator programis performed according to a predefined template.

[0035] According to another aspect of the method, the second protocol isSOAP.

[0036] A further aspect of the method includes installing an API in theclient for access by the application program.

[0037] According to yet another aspect of the method, the proxy codeincludes a synchronous stub.

[0038] According to still another aspect of the method, the proxy codeincludes an asynchronous stub.

[0039] According to an additional aspect of the method, the proxy codeincludes a grouped stub.

[0040] According to one aspect of the method, the proxy code includesinstructions for enablement of HTTP for transport of the first messages.

[0041] According to another aspect of the method, the proxy codeincludes instructions for enablement of HTTPS for transport of the firstmessages.

[0042] According to a further aspect of the method, the proxy codeincludes no more than one procedure for accessing the server-sideservices.

[0043] According to another aspect of the method, the proxy codeincludes a plurality of Java classes.

[0044] The invention provides a method of communication between a clientoperating in a first platform-independent environment and a serveroperating in a second platform-independent environment over a datanetwork to obtain a supported service for the client via the server,which is carried out at the client by encoding a request for the serviceaccording to a first format to define an encoded message, andtransmitting the encoded message to a mediator via the data network. Themethod is further carried out at the mediator by re-encoding the encodedmessage into a second format to define a re-encoded message, wherein thesize of the re-encoded message exceeds the size of the encoded message,and transmitting the re-encoded message to a provider of the service viathe data network.

[0045] The invention provides A computer software product, comprising acomputer-readable medium in which computer program instructions arestored, which instructions, when read by a computer, cause the computerto perform a method for enabling communication between a clientoperating in a first platform-independent environment and a serveroperating in a second platform-independent environment to obtain aservice for the client via the server, which is carried out at theclient by encoding a request for the service according to a first formatto define an encoded message, and transmitting the encoded message to amediator. The method is further carried out at the mediator byre-encoding the encoded message into a second format, wherein the sizeof the re-encoded message exceeds the size of the encoded message, andtransmitting the re-encoded message to a provider of the service.

[0046] The invention provides a computer software product, including acomputer-readable medium in which computer program instructions arestored, which instructions, when read by a computer, cause the computerto perform a method of establishing access by a client operating in afirst platform-independent environment to a server operating in a secondplatform-independent environment to obtain predetermined server-sideservices, which is carried out by generating proxy code for installationin the client to provide an interface with an application programexecuting therein, wherein requests for the server-side services aregenerated by the application program, and the proxy code is adapted toreformulate the requests as first messages according to a firstprotocol, and generating a mediator program for installation in acomputing device external to the client. The mediator program acceptsinput from the client according to the first protocol, and is furtheradapted to reformulate the first messages as second messages accordingto a second protocol. The computing device is capable of communicatingthe second messages to a provider of the server-side services.

[0047] The invention provides a computer software product, including acomputer-readable medium in which computer program instructions arestored, which instructions, when read by a computer, cause the computerto perform a method of establishing an interaction between a clientoperating in a first platform-independent environment to a serveroperating in a second platform-independent environment over a datanetwork to obtain a supported service for the client via the server,which is carried out by generating a first program for installation inthe client, which when executed by the client causes the client toencode a request for the service according to a first format to definean encoded message, and to transmit the encoded message to the servervia the data network. The method is further carried out by generating asecond program for installation in the server, which when executed bythe server causes the server to re-encode the encoded message into asecond format, wherein the size of the re-encoded message exceeds thesize of the encoded message, and to transmit the re-encoded message to aprovider of the service via the data network.

[0048] The invention provides a development system for establishingaccess by a client to predetermined server-side services, including acomputer having a code generator executing therein in a firstplatform-independent environment. The code generator is adapted togenerate proxy code executable in the client to provide an interfacewith an application program executing in the client, wherein requestsfor the server-side services, are generated by the application program.The proxy code is adapted to reformulate the requests as first messagesaccording to a first protocol. The client operates in a secondplatform-independent environment, and the code generator is furtheradapted to generate a mediator program for a computing device externalto the client, the mediator program accepting input from the clientaccording to the first protocol and being further adapted to reformulatethe first messages as second messages according to a second protocol.The computing device is capable of communicating the second messages toa provider of the server-side services.

[0049] According to a further aspect of the development system, the codegenerator is actuated using a command line interface.

[0050] According to yet another aspect of the development system, thecode generator is linked to an integrated development program.

[0051] According to still another aspect of the development system, theprovider of the server-side services is a Java-enabled server.

[0052] According to an additional aspect of the development system, theclient is a Java-enabled client.

[0053] According to one aspect of the development system, the mediatorprogram is compiled from Java source code by the code generator.

[0054] According to one aspect of the development system, the firstmessages are smaller than corresponding ones of the second messages.

[0055] According to an additional aspect of the development system, thefirst messages each comprise a plurality of the requests.

[0056] According to still another aspect of the development system, aninput of the code generator includes a predefined template.

[0057] According to another aspect of the development system, thetemplate includes Java source code, wherein at least a part of the Javasource code is copied by the code generator to an output file.

[0058] According to a further aspect of the development system, thetemplate also includes a logical directive that specifies the part ofthe Java source code.

[0059] According to yet another aspect of the development system, themediator program is generated by the code generator responsively to thetemplate.

[0060] According to a further aspect of the development system, thesecond protocol is SOAP.

[0061] According to yet another aspect of the development system, theproxy code includes proxy classes.

[0062] According to another aspect of the development system, the proxycode includes a synchronous stub.

[0063] According to one aspect of the development system, the proxy codeincludes an asynchronous stub.

[0064] According to an additional aspect of the development system, theproxy code includes a grouped stub.

[0065] According to still another aspect of the development system, theproxy code includes instructions for enablement of HTTP for transport ofthe first messages.

[0066] According to yet another aspect of the development system, theproxy code includes instructions for enablement of HTTPS for transportof the first messages.

[0067] According to a further aspect of the development system, theproxy code includes no more than one procedure for accessing theserver-side services.

BRIEF DESCRIPTION OF THE DRAWINGS

[0068] For a better understanding of these and other objects of thepresent invention, reference is made to the detailed description of theinvention, by way of example, which is to be read in conjunction withthe following drawings, wherein:

[0069]FIG. 1 is a block diagram of a system for providing end-to-endcommunication between a client and a server that is constructed andoperative in accordance with a disclosed embodiment of the invention;

[0070]FIG. 2 is a block diagram of a system for developing specializedclient and server software for a MIDP device that requires J2EE servicesin accordance with a disclosed embodiment of the invention;

[0071]FIG. 3 is a detailed block diagram of a development tool in thesystem shown in FIG. 2 in accordance with a disclosed embodiment of theinvention;

[0072]FIG. 4 is a flow chart indicating a method of preparingspecialized software to enable a client to access a server to obtain webservices in accordance with a disclosed embodiment of the invention; and

[0073]FIG. 5 is a flow chart illustrating a method of using an optimizedprotocol in a client-server end-to-end communication in accordance witha disclosed embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0074] In the following description, numerous specific details are setforth in order to provide a thorough understanding of the presentinvention. It will be apparent to one skilled in the art, however, thatthe present invention may be practiced without these specific details.In other instances well-known circuits, control logic, and the detailsof computer program instructions for conventional algorithms andprocesses have not been shown in detail in order not to unnecessarilyobscure the present invention.

[0075] Software programming code, which embodies aspects of the presentinvention, is typically maintained in permanent storage, such as acomputer readable medium. In a client-server environment, such softwareprogramming code may be stored on a client or a server. The softwareprogramming code may be embodied on any of a variety of known media foruse with a data processing system, such as a diskette, or hard drive, orCD-ROM. The code may be distributed on such media, or may be distributedto users from the memory or storage of one computer system over anetwork of some type to other computer systems for use by users of suchother systems. The techniques and methods for embodying software programcode on physical media and distributing software code via networks arewell known and will not be further discussed herein.

Architecture

[0076] Reference is now made to FIG. 1, which is a block diagram of asystem 10 for providing end-to-end communication between a client and aserver that is constructed and operative in accordance with a disclosedembodiment of the invention. A resource-constrained client, operating ina platform-independent environment designed for small clients,represented by a mobile information device 12, is connected to a datanetwork 14, which can be the Internet. The mobile information device 12is typically a J2ME client. An application or content server 16 operatesin a platform-independent environment designed for devices havinggreater capabilities than the mobile information device 12. The server16 is typically a J2EE-enabled server operated by a content provider ora service provider, and is connected to the data network 14. Aspecialized MIDlet 18 executing on the mobile information device 12requests desired services or content from the server 16. The system 10includes a gateway server 20 that is connected to the data network 14. Amediator servlet 22 resides on the server 20, and acts as a gatewaybetween the mobile information device 12 and the server 16. Thus, unlikeconventional data network communication, data does not always flowdirectly between the mobile information device 12 and the server 16, aswill be explained in further detail hereinbelow. Alternatively, themediator servlet 22 may reside on the server 16 together with the serverapplication software.

[0077] The mediator servlet 22 is typically generated by a developer 24,in conjunction with the development of the MIDlet 18. In someembodiments the mediator servlet 22, or a replica thereof (not shown),may be accessible to the developer 24 via the server 20 across the datanetwork 14. Additionally or alternatively, the developer 24 could accessthe mediator servlet 22 via a direct link to the server 20. In eithercase, the developer 24 is able, using a development tool 26 in theserver 20, to optimize the MIDlet 18 according to the particular contentor services being sought from the server 16, and the characteristics ofthe mobile information device 12. Alternatively, the development tool 26may be located in a different development machine 28, as indicated by adotted line 30.

[0078] Reference is now made to FIG. 2, which is a block diagram of anarrangement 32 for developing specialized client and server software foruse by a MIDP device, such as a J2ME-enabled mobile information device,that requires J2EE services in accordance with a disclosed embodiment ofthe invention. The disclosure of FIG. 2 should be read in conjunctionwith FIG. 1, in which like elements are given like reference numerals.Portions of the arrangement 32 may be incorporated within the mediatorservlet 22 (FIG. 1), or may reside on a separate development platform.The arrangement 32 generally conforms to a client-server model, in whicha client-server division is indicated by a vertical line 34. A J2MEclient 36 has the MIDlet 18 installed therein. The code of the MIDlet 18is typically written by the developer 24 (FIG. 1). An API set 38,consisting of one or more conventional MIDP API's, is installed in theclient 36. For example, the API set 38 could include the J2ME MobileMedia API, which provides audio, video and other time-based multimediasupport to resource-constrained devices, and allows the developer 24 togain access to native multimedia services available on the client 36.

[0079] J2ME proxy classes 40 are included in the MIDlet 18 that isinstalled in the client 36, which enables it to access web services. Theproxy classes 40 are automatically generated by the development tool 26,based on definitions of web services and preferences supplied by thedeveloper 24 (FIG. 1). A code generator 42 is provided in thedevelopment tool 26. In some embodiments, the developer 24 accesses thedevelopment tool 26 interactively, using a graphical user interface 27.In other embodiments, the developer 24 non-interactively submitsinformation, for example parameters, to the development tool 26.

[0080] A mediator server 44 is generally indicated on the right side ofthe arrangement 32. The server-side mediator servlet 22 interacts withthe proxy classes 40 through a customized and optimized protocol 46,optimized for low network bandwidth and easy parsing. The mediatorservlet 22 is automatically generated by the development tool 26. Themediator servlet 22 interprets web service requests from the client 36and delivers them to appropriate providers of web services 48, 50 usinga standard protocol 52, which can be SOAP, or another standard protocol54. The web services 48, 50 may be hosted on the same or a differentserver as the mediator server 44. When the mediator servlet 22 receivesresponses from the web services 48, 50, it relays them back to theclient 36 using the optimized protocol 46, or a different optimizedprotocol. The web services 48, 50 may be created by the developer 24(FIG. 1), or by another developer (not shown).

Proxy Classes

[0081] With continued reference to FIG. 1 and FIG. 2, the proxy classes40 (FIG. 2) contain as simple an interface as possible. Thus, from theperspective of the developer 24 (FIG. 1), developing code using an APIprovided by a web service is hardly different from developing code usinga local API. For example, a web service providing the API shown inListing 1 may be represented on the client 36 by the code shown inListing 2. Listing 1 public class HelloService { public StringsayHello(String name) { return “Hello” + name + “!” } } Listing 2 publicclass HelloServiceProxy { public String sayHello(String name) throwsIOException { // code to communicate with the service // via themediator // and return the result } }

[0082] The MIDlet 18 could call the service of Listing 2 using asynchronous call, as shown in Listing 3. Listing 3 String server =http://www.example.com/services/mediator“; HelloService service = newHelloServiceProxy(server); try { String greeting =service.sayHello(“World”); } catch (IOException ioe) { // exceptionhandling }

Client Agent

[0083] Referring again to FIG. 1 and FIG. 2, the client 36 preferablyhas minimum memory requirements, both in terms of static footprint andof heap memory requirements. At the present time, in order to beacceptable to developers, it is recommended that no more than 15 Kbytesbe preempted by the client 36.

[0084] There are other general considerations in the design of theMIDlet 18 and the proxy classes 40. It is desirable that a minimumamount of processing occurs in the client 36. Since mobile informationdevices typically have low network bandwidth and high latency, theclient agent should generate a minimum amount of network traffic.

[0085] As noted above, asynchronous calls to web services are supportedin the proxy classes 40, and as the HTTP protocol is an essentialnetwork protocol for MIDP devices, it is well supported. The clientagent also supports the HTTPS protocol, and can be adapted to supportall protocols supported by MIDP, Version 1.0, and is sufficientlyflexible to support many other any protocols, limited only by thecapabilities of the client 36.

Client Protocol

[0086] With continued reference to FIG. 1 and FIG. 2, the optimizedprotocol 46 used by the proxy classes 40 for communication with themediator servlet 22 is configured according to the characteristics ofthe API set 38. Thus, asynchronous requests may be grouped together intoa single request to improve efficiency. This may be achieved by addingan artificial latency for example, 100 ms., after a request, duringwhich time any additional requests are bundled together with the firstrequest.

Server Protocols

[0087] With continued reference to FIG. 1 and FIG. 2, the mediatorservlet 22 uses SOAP as the standard protocol 52 for communicating withservices, for example the web services 48, which must be SOAP enabledweb services.

[0088] It will be understood that while the web services 48, 50 areshown in FIG. 2, the mediator servlet 22 is not limited to communicatingwith web services, nor to SOAP, or even the use of the HTTP protocol.The mediator servlet 22 can communicate with many remote services. Forthose remote services that use non-standard protocols, the developer 24(FIG. 1) must provide classes (not shown) for communication between themediator servlet 22 and the remote services using the remote services'respective protocols. The mediator servlet 22 calls a developer-providedclass in order to effect the communication. Although only two standardprotocols 52, 54 are illustrated representatively in FIG. 2, manydifferent standard and non-standard protocols can be used in accordancewith the requirements of different web services. Indeed, virtually allnon-standard custom protocols can be used, so long as the developer 24(FIG. 1) is aware of their specifications, so that an appropriate classcan be included in the mediator servlet 22.

Code Generation Tool

[0089] With continued reference to FIG. 1 and FIG. 2, the mediatorservlet 22 is built automatically by the development tool 26. It acts asa translator between the optimized protocol 46 and the standardprotocols 52, 54. The code generator 42 generates Java source code forthe proxy classes 40 and the mediator servlet 22. Optionally, thegeneration of the proxy classes 40 and the mediator servlet 22 includesa specification of the network transport on which communication occurs,for example, HTTP, HTTPS, SMS, socket or secure socket. The codegenerator 42 recognizes a directive to, generate debugging classes withtracing statements, and a directive to generate optimized classes fordeployment as the proxy classes 40.

[0090] Details of web services are obtained by the development tool 26in two ways. For web services that are defined in WSDL, all necessaryinformation can be obtained from the WSDL definitions and the locationof the web service. For other J2EE services, the developer 24 (FIG. 1)must provide details of the service in the form of a Java interface andthe name of an implementing class to the development tool 26.

[0091] The code generator 42 may be implemented using the Sun ONE Studiointegrated development environment, available from Sun Microsystems,Inc. Alternatively, the code generator 42 may have a command-lineinterface, or can be provided with a Java API. Alternatively, the codegenerator 42 can be implemented as a stand-alone tool, having its ownuser interface

[0092] Reference is now made to FIG. 3, which is a detailed blockdiagram of the development tool 26 (FIG. 2) in accordance with adisclosed embodiment of the invention. The description of FIG. 3 shouldbe read in conjunction with FIG. 2, in which like elements are givenlike reference numerals. The code generator 42 can be regarded as thecore of the development tool 26. It employs code templates 56 in orderto create the proxy classes 40 and the mediator servlet 22 (FIG. 2). Thecode generator 42 is accessible via an internal API 58 using a commandline interface 60 to supply input data 62 that enables the codegenerator 42 to parameterize the code that it produces. Alternatively,an integrated development environment 64, for example, the Sun ONEStudio, may be linked to the API 58 in order to control the codegenerator 42.

[0093] The input data 62 supplied to the code generator 42, either viathe command line interface 60 or the integrated development environment64, include the names of classes and methods to be exported by theserver to the client, details of what output files are to be generated,and where they are to be placed. The input data 62 further include afeature set that is to be supported by the generated client code.Options within the feature set include dynamic invocation, synchronousstubs, asynchronous stubs, grouped stubs, and enablement of HTTP orHTTPS as the underlying network protocol.

[0094] If the dynamic invocation option is elected, the client codeincludes a single method with a name such as invokeServer( ), which isused to access all functions of the server.

[0095] If the synchronous stubs option is elected, then each methodexported from the server to the client has a corresponding method on theclient for accessing the server, which does not return control to thecalling application until the call to the server has completed.

[0096] If the asynchronous stubs option is elected, then each methodexported from the server to the client has its own method on the client,which calls the server and returns control to the calling applicationimmediately. Results from the call are retrieved through an interfaceusing the listener model.

[0097] If the grouped stubs option is elected, then each method exportedfrom the server to the client has its own method on the client. Thismethod prepares a call to the server but does not actually call it untilyet another method, here termed syncGroup( ), is called. Using thismechanism, multiple calls to methods on the server can be made using asingle HTTP or HTTPS connection.

[0098] The code generator 42 loads one or more of the code templates 56in preparation for generating its output. Each of the code templates 56is a blueprint for the code to be generated. It contains two interleavedparts, data 66, and logic 68. The data 66 consists of Java source code,which is to be copied verbatim to output files. The logic 68 istypically Java byte code, (e.g., J2ME proxy classes and theirinfrastructure) that is executed during code generation to control whatparts of the data 66 are to be copied to the mediator servlet 22. Forexample, the logic 68 in one of the code templates 56 may ensure thatdata 66 that contains code to support grouped calls, or to handlereceiving arrays of strings from the server, is only included if thereis an explicit user requirement for such functionality, or an implicitrequirement that can be inferred from the configuration data. Byappropriately configuring the data 66 and the logic 68, the codetemplates 56 relieves the developer 24 (FIG. 1) of much of the burden ofproviding detailed code. Code templates can be provided for manydifferent products that can function as the mobile information device 12(FIG. 1), Similarly, different code templates can be prepared fordifferent web services. As the clients and web services encounteredtoday are so diverse, it is likely that large catalogs of code templates56 will be maintained for use by the code generator 42. The output ofthe code generator 42, and the optimized protocol 46 (FIG. 2) isinfluenced by the input data 62, in which the developer 24 (FIG. 1)specifies the protocol with which the mediator servlet 22 is tocommunicate with the remote service. As mentioned above, the developer24 has wide latitude to select a standard or a non-standard protocol.

[0099] When the code templates 56 are used to generate source code forthe client and the server, they are parameterized with the input data 62that were supplied via the command line interface 60 or the integrateddevelopment environment 64.

[0100] Included in the logic 68 is code that specializes the optimizedprotocol 46 (FIG. 2). When the mediator servlet 22 on the mediatorserver 44 receives a call from the client 36, it needs to determinewhich method of the requested service is to be invoked. The client 36sends it an integer identification code identifying the requestedmethod. This identification code is fixed at the time the proxy classes40 and the mediator servlet 22 are generated by the development tool 26.

EXAMPLE 1

[0101] This example is presented with continued reference to FIG. 2 andFIG. 3. A class StockService on a server offering the web services 48has three methods by which particular services can be supplied to theclient 36: getStockTickers( ), getStockName( ), and getStockValue( ).Each of these three methods is assigned a unique integer identificationcode. When the client 36 invokes one of these methods from the webservices 48, it transmits a message to the mediator servlet 22 using thefollowing 3-part protocol: (1) an integer code indicating that a commandis about to be sent; (2) the identification code integer identifying therequested method; and (3) the paramaters of the requested method. The3-part protocol is specified by the developer 24 (FIG. 1), who alsospecifies which methods are allowed to be called from the client 36. Anyun-needed functionality is intentionally omitted from the 3-partprotocol by the development tool 26 at code generation time.

[0102] Assume that the client 36 is a stock tracking MIDlet. First, itqueries the web services 48 to get the list of stock tickers for whichit can provide data.

[0103] The client 36 sends a request as shown in Listing 4 to themediator servlet 22, and waits for a response, which it expects to be alist of text strings. The mediator servlet 22 receives the request andsends a SOAP request to the server hosting the web services 48, as shownin Listing 5. Listing 4 (32-bit integer): 1 (code for a remote servicerequest) (32-bit integer): 1 (one element in this request) (32-bitinteger): 5 (code for “getStockTickers” ser-  vice) Listing 5 <?xmlversion=‘1.0’ encoding=‘UTF-8’?> <SOAP-ENV:Envelopexmlns:SOAP-ENV=“http: // schemas.xmlsoap.org/soap/envelope/”xmlns:xsi=“http://www.w3.org/1999/XMLSchema- instance”xmlns:xsd=“http://www.w3.org/1999/XMLSchema”> <SOAP-ENV:Body> etc.

[0104] The mediator servlet 22 receives a SOAP response, as shown inListing 6. Listing 6 <?xml version=‘1.0’ encoding=‘UTF-8’?><SOAP-ENV:Envelope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”xmlns:xsi=“http://www.w3.org/1999/XMLSchema-instance”xmlns:xsd=“http://www.w3.org/1999/XMLSchema”> <SOAP-ENV:Body> etc.

[0105] The SOAP response contains a list of supported stock tickers (say“SUNW”, “IBM” and “MSFT”), which the mediator servlet 22 relays to thewaiting client 36, as shown in Listing 7. Listing 7 (32-bit integer): 1(code for successful operation) (32-bit integer): 3 (three elements instring array) (32-bit integer): 4 (four bytes in first string) SUNW(32-bit integer): 3 (four bytes in second string) IBM (32-bit integer):4 (four bytes in first string) MSFT

[0106] The client 36 receives this data and then closes the connectionto the mediator servlet 22. The client 36 now wants to get the fullbusiness names for the stickers “SUNW” and “IBM”. It sends a groupedrequest to the mediator servlet 22, as shown in Listing 8, and waits fora response. Listing 8 (32-bit integer): 1 (code for a remote service re- quest) (32-bit integer): 2 (two elements in this request) (32-bitinteger): 8 (code for “getStockName” service) (32-bit integer): 4(number of bytes in string about to  be sent) SUNW (32-bit integer): 8(code for “getStockName” service) (32-bit integer): 3 (number of bytesin string about to  be sent) IBM

[0107] The mediator servlet 22 receives this grouped request, which inthis example is a pair of requests. For each request in turn, themediator servlet 22 composes and sends a SOAP request to a remoteservice to receive the company names for the stock ticker, which may bethe same or a different service than the web services 48. The mediatorservlet 22 then receives the SOAP response and extracts criticalinformation. The mediator servlet 22 then returns this information tothe waiting client 36, as shown in Listing 9. Listing 9 (32-bitinteger): 1 (code for successful operation) (32-bit integer): 22(twenty-two elements in string ar-  ray) Sun Microsystems, Inc. (32-bitinteger) 1 (code for successful operation) (32-bit integer): 44(forty-four elements in string ar-  ray) International Business MachinesCorporation

[0108] The client 36 receives the response shown in Listing 9, anddisconnects from the mediator servlet 22.

Client Code Size Reduction

[0109] As shown in Example 1, and with continued reference to FIG. 2 andFIG. 3, the code generator 42 is constructed to exclude unused andunneeded code from the proxy classes 40 and the mediator servlet 22. Thelogic 68 in the code templates 56 (FIG. 3) ensures that only code forrequired features and data types is generated by the code generator 42.For example, if no Boolean value is ever returned by the web services48, 50, the client 36 is not provided any code for dealing with Booleanreturn values.

Client Code Optimization

[0110] Continuing to refer to FIG. 2 and FIG. 3, in addition to simplynot generating code for unneeded features, the code generator 42 canapply other optimizations based on its intimate knowledge of the exactrequirements specified by the developer 24 (FIG. 1). The followingoptimizations are examples.

[0111] The code generator 42 may generate inline code for methods thatare used only once or twice, and generate invokable method code formethods that are called more frequently.

[0112] The code generator 42 may evaluate more than one algorithm forthe client source code, and employ the one most appropriate to thebalance of stub methods that are generated, in accordance with the logic68 in the code templates 56. For example, if there are only a fewsynchronous stubs to be generated, then the logic 68 may recognize thatcode space can be conserved by generating stub code that writes directlyto a HTTP, or HTTPS output stream, instead of using a default genericmechanism.

Operation

[0113] Reference is now made to FIG. 4, which is a flow chart indicatinga method of preparing specialized software to enable a client to accessa server to obtain remote services in accordance with a disclosedembodiment of the invention. The process begins at initial step 70,wherein software specifications are prepared. Here a developer specifieswhich remote services are intended to be accessed by the client.

[0114] Next, at step 72, input data, typically parameters, areintroduced at this time, for use by the code templates as parametersduring code generation. A development tool is typically employed at thisstep, as disclosed hereinabove. Code templates appropriate to theparticular client and most closely adapted to the desired remoteservices are automatically selected and loaded by a code generator.

[0115] Next, at step 74, proxy classes are generated by the developer,using a development tool. Included in the proxy classes are classeshaving methods that invoke desired remote services. The methods encryptrequests for remote services into a form that is more compact thanrequests produced by the API's that were installed in step 74. One ormore of such requests is then incorporated into a transmission packagein accordance with a specified optimized protocol. Other methods dealwith receipt of encoded data and their decoding into conventional dataformats.

[0116] Next, at step 76 a MIDlet is encoded by the developer, andinstalled in the client. The MIDlet is dependent on the proxy classes,which were generated at step 74. Typically, an emulator is used todevelop the MIDlet. The remote services to be accessed by the MIDletcorrespond to the remote services that are dealt with by the codetemplates that were selected at step 72. Typically, the MIDlet codeemploys calls made available by the API's that were installed in step74.

[0117] Next, at step 78 a mediator servlet is generated and installed ona server. The mediator servlet is configured to use the optimizedprotocol, and to translate encrypted information into invocations ofrequested remote services using a standard protocol, for example SOAP.The mediator servlet is also constructed to perform an inverseoperation, wherein results received as a result of requests for remoteservices are encrypted into the same or a different optimized protocolfor retransmission to the client.

[0118] At final step 82 network connections are established, and theclient-server system can be placed into operation.

[0119] Reference is now made to FIG. 5, which is a flow chartillustrating a method of using an optimized protocol in client-serverend-to-end communication in accordance with a disclosed embodiment ofthe invention. The process begins at initial step 84, where a client anda server are configured using the procedure set forth in FIG. 4. Theprocess steps are shown in a particular sequence in FIG. 5 for clarityof presentation. However, it will be evident that many of them can beperformed in parallel, asynchronously, or in different orders.

[0120] Next, at step 86, a client request for a remote service is nowformulated, and encoded according to the optimized protocol. Typically,an identification code is assigned to each allowable service andsubstituted for the conventional service identification. The parameterlist of the individual services may also be encoded in a compressedformat.

[0121] Control now passes to step 88, where the encoded information istransmitted from the client to the server.

[0122] Next, at step 90 at the server an encoded message is decoded. Aremote service request is identified, together with any parameters. Therequest is reformulated in accordance with a standard protocol, forexample SOAP.

[0123] Next, at step 92, the remote service identified in step 90 isaccessed by the server using the standard protocol. The remote servicemay be provided on the same server as decoded the message, or on adifferent server.

[0124] Control now passes to decision step 94, where it is determined ifthere are more service requests to be encoded. If the determination atdecision step 94 is affirmative, then control returns to step 90.

[0125] If the determination at decision step 94 is negative, then theresults of the service requests submitted in step 92 are awaited andprocessed. Control proceeds to step 96, where all currently receivedresults are encoded according to the optimized protocol. Typically, theidentification code assigned to a particular service is substituted forthe conventional service identification. The results obtained from eachof the individual services are also encoded in compressed format.

[0126] Control proceeds to step 98, where the encoded information istransmitted from the server to the client.

[0127] Next, at step 100 at the client an encoded message is decoded. Aremote service is identified in the message, together with theaccompanying results.

[0128] Next, at step 102, the results that were decoded at step 100 areprocessed by client software. For example, they may be formatted andvisually displayed.

[0129] Control now passes to decision step 104, where it is determinedif there are more service requests to be encoded. If the determinationat decision step 104 is affirmative, then control returns to step 100.

[0130] If the determination at decision step 104 is negative, thencontrol proceeds to final step 106, and the process terminates.

[0131] It will be appreciated by persons skilled in the art that thepresent invention is not limited to what has been particularly shown anddescribed hereinabove. Rather, the scope of the present inventionincludes both combinations and sub-combinations of the various featuresdescribed hereinabove, as well as variations and modifications thereofthat are not in the prior art, which would occur to persons skilled inthe art upon reading the foregoing description.

1. A method of communication between a client operating in a firstplatform-independent environment to a server operating in a secondplatform-independent environment to obtain a service for said client viasaid server, comprising the steps of: compiling a program for saidclient from a platform-independent source code; using said program togenerate a request for said service by said client; at said clientencoding said request according to a first format to define an encodedmessage; transmitting said encoded message to a mediator; at saidmediator re-encoding said encoded message into a second format to definea re-encoded message, wherein a size of said re-encoded message exceedsa size of said encoded message; and transmitting said re-encoded messageto a provider of said service.
 2. The method according to claim 1,wherein said program has only a minimum code that is required to producesaid first format.
 3. The method according to claim 1, wherein said stepof re-encoding said encoded message is performed by decoding saidencoded message to define a decoded message, and re-encoding saiddecoded message into said second format.
 4. The method according toclaim 1, wherein said request comprises a plurality of requests that areassembled into an encoded message group in said encoded message.
 5. Themethod according to claim 4, further comprising the step of delayingperformance of said step of encoding said request for a latency intervalto await pendency of additional ones of said plurality of requests. 6.The method according to claim 4, wherein said plurality of requests areasynchronously initiated.
 7. The method according to claim 1, whereinsaid second format is SOAP.
 8. A method of establishing access by aclient to predetermined server-side services, comprising the steps of:installing proxy code in said client to provide an interface with anapplication program executing therein, wherein requests for saidserver-side services are generated by said application program and saidproxy code is adapted to reformulate said requests as first messagesaccording to a first protocol; and executing a mediator program in acomputing device external to said client, said mediator programaccepting input from said client according to said first protocol andbeing further adapted to reformulate said first messages as secondmessages according to a second protocol, said computing device beingcapable of communicating said second messages to a provider of saidserver-side services.
 9. The method according to claim 8, wherein saidfirst messages are smaller than corresponding ones of said secondmessages.
 10. The method according to claim 8, wherein said firstmessages each comprise a plurality of said requests.
 11. The methodaccording to claim 8, wherein said step of installing proxy codecomprises automatically generating said proxy code substantially withouthuman intervention.
 12. The method according to claim 11, wherein saidstep of generating said proxy code is performed according to apredefined template.
 13. The method according to claim 8, wherein saidstep of executing a mediator program comprises automatically generatingsaid mediator program substantially without human intervention.
 14. Themethod according to claim 13, wherein said step of generating saidmediator program is performed according to a predefined template. 15.The method according to claim 8, wherein said second protocol is SOAP.16. The method according to claim 8, further comprising the step ofinstalling an API in said client for access by said application program.17. The method according to claim 8, wherein said proxy code comprises asynchronous stub.
 18. The method according to claim 8, wherein saidproxy code comprises an asynchronous stub.
 19. The method according toclaim 8, wherein said proxy code comprises a grouped stub.
 20. Themethod according to claim 8, wherein said proxy code comprisesinstructions for enablement of HTTP for transport of said firstmessages.
 21. The method according to claim 8, wherein said proxy codecomprises instructions for enablement of HTTPS for transport of saidfirst messages.
 22. The method according to claim 8, wherein said proxycode comprises no more than one procedure for accessing said server-sideservices.
 23. The method according to claim 8, wherein said proxy codecomprises a plurality of Java classes.
 24. A method of communicationbetween a client operating in a first platform-independent environmentand a server operating in a second platform-independent environment overa data network to obtain a supported service for said client via saidserver, comprising the steps of: at said client encoding a request forsaid service according to a first format to define an encoded message;transmitting said encoded message to a mediator via said data network;at said mediator re-encoding said encoded message into a second formatto define a re-encoded message, wherein a size of said re-encodedmessage exceeds a size of said encoded message; and transmitting saidre-encoded message to a provider of said service via said data network.25. The method according to claim 24, wherein said step of re-encodingsaid encoded message is performed by decoding said encoded message todefine a decoded message; and re-encoding said decoded message into saidsecond format.
 26. The method according to claim 24, wherein saidrequest comprises a plurality of requests that are assembled into anencoded message group in said encoded message.
 27. The method accordingto claim 26, further comprising the step of delaying performance of saidstep of encoding a request for a latency interval to await pendency ofadditional ones of said plurality of requests.
 28. The method accordingto claim 26, wherein said plurality of requests are asynchronouslyinitiated.
 29. The method according to claim 24, wherein said secondformat is SOAP.
 30. A computer software product, comprising acomputer-readable medium in which computer program instructions arestored, which instructions, when read by a computer, cause the computerto perform a method of communication between a client operating in afirst platform-independent environment and a server operating in asecond platform-independent environment to obtain a service for saidclient via said server, comprising the steps of: at said client encodinga request for said service according to a first format to define anencoded message; transmitting said encoded message to a mediator; atsaid mediator re-encoding said encoded message into a second format todefine a re-encoded message, wherein a size of said re-encoded messageexceeds a size of said encoded message; and transmitting said re-encodedmessage to a provider of said service.
 31. The computer software productaccording to claim 30, wherein said step of re-encoding said encodedmessage is performed by decoding said encoded message to define adecoded message; and re-encoding said decoded message into said secondformat.
 32. The computer software product according to claim 30, whereinsaid request comprises a plurality of requests that are assembled intoan encoded message group in said encoded message.
 33. The computersoftware product according to claim 32, wherein said computer is furtherinstructed to delay performance of said step of encoding a request for alatency interval to await pendency of additional ones of said pluralityof requests.
 34. The computer software product according to claim 32,wherein said plurality of requests are asynchronously initiated.
 35. Thecomputer software product according to claim 30, wherein said secondformat is SOAP.
 36. A computer software product, comprising acomputer-readable medium in which computer program instructions arestored, which instructions, when read by a computer, cause the computerto perform a method of establishing access by a client operating in afirst platform-independent environment to a server operating in a secondplatform-independent environment to obtain predetermined server-sideservices, comprising the steps of: generating proxy code forinstallation in said client to provide an interface with an applicationprogram executing therein, wherein requests for said server-sideservices are generated, by said application program and said proxy codeis adapted to reformulate said requests as first messages according to afirst protocol; and generating a mediator program for installation in acomputing device external to said client, said mediator programaccepting input from said client according to said first protocol andbeing further adapted to reformulate said first messages as secondmessages according to a second protocol, said computing device beingcapable of communicating said second messages to a provider of saidserver-side services.
 37. The computer software product according toclaim 36, wherein said application program has only a minimum protocolgeneration code that is required to produce said first messages in saidfirst protocol.
 38. The computer software product according to claim 36,wherein said first messages are smaller than corresponding ones of saidsecond messages.
 39. The computer software product according to claim36, wherein said first messages each comprise a plurality of saidrequests.
 40. The computer software product according to claim 36,wherein said step of generating proxy code is performed substantiallywithout human intervention.
 41. The computer software product accordingto claim 40, wherein said step of generating proxy code is performedaccording to a predefined template.
 42. The computer software productaccording to claim 36, wherein said step of generating a mediatorprogram is performed substantially without human intervention.
 43. Thecomputer software product according to claim 42, wherein said step ofgenerating a mediator program is performed according to a predefinedtemplate.
 44. The computer software product according to claim 36,wherein said second protocol is SOAP.
 45. The computer software productaccording to claim 36, further comprising the step of installing an APIin said client for access by said application program.
 46. The computersoftware product according to claim 36, wherein said proxy codecomprises a synchronous stub.
 47. The computer software productaccording to claim 36, wherein said proxy code comprises an asynchronousstub.
 48. The computer software product according to claim 36, whereinsaid proxy code comprises a grouped stub.
 49. The computer softwareproduct according to claim 36, wherein said proxy code comprisesinstructions for enablement of HTTP for transport of said firstmessages.
 50. The computer software product according to claim 36,wherein said proxy code comprises instructions for enablement of HTTPSfor transport of said first messages.
 51. The computer software productaccording to claim 36, wherein said proxy code comprises no more thanone procedure for accessing said server-side services.
 52. The computersoftware product according to claim 36, wherein said proxy codecomprises a plurality of Java classes.
 53. A computer software product,comprising a computer-readable medium in which computer programinstructions are stored, which instructions, when read by a computer,cause the computer to perform a method of establishing an interactionbetween a client operating in a first platform-independent environmentto a server operating in a second platform-independent environment overa data network to obtain a supported service for said client via saidserver, comprising the steps of: generating a first program forinstallation in said client, which when executed by said client causessaid client to perform the steps of: encoding a request for said serviceaccording to a first format to define an encoded message; andtransmitting said encoded message to said server via said data network;and generating a second program for installation in said server, whichwhen executed by said server causes said server to perform the steps of:re-encoding said encoded message into a second format to define are-encoded message, wherein a size of said re-encoded message exceeds asize of said encoded message; and transmitting said re-encoded messageto a provider of said service via said data network.
 54. The computersoftware product according to claim 53, wherein said step of re-encodingsaid encoded message is performed by decoding said encoded message todefine a decoded message; and re-encoding said decoded message into saidsecond format.
 55. The computer software product according to claim 53,wherein said request comprises a plurality of requests that areassembled into an encoded message group in said encoded message.
 56. Thecomputer software product according to claim 55, wherein said client isfurther instructed to delay performance of said step of encoding arequest for a latency interval to await pendency of additional ones ofsaid plurality of requests.
 57. The computer software product accordingto claim 55, wherein said plurality of requests are asynchronouslyinitiated.
 58. The computer software product according to claim 53,wherein said second format is SOAP.
 59. A development system forestablishing access by a client to predetermined server-side services,comprising: a computer having a code generator executing therein withina first platform-independent environment, said code generator beingadapted to generate proxy code executable in said client to provide aninterface with an application program executing in said client, whereinrequests for said server-side services are generated by said applicationprogram and said proxy code is adapted to reformulate said requests asfirst messages according to a first protocol, wherein said clientoperates in a second platform-independent environment; and said codegenerator being further adapted to generate a mediator program for acomputing device external to said client, said mediator programaccepting input from said client according to said first protocol andbeing further adapted to reformulate said first messages as secondmessages according to a second protocol, said computing device beingcapable of communicating said second messages to a provider of saidserver-side services.
 60. The development system according to claim 59,wherein said code generator is actuated using a command line interface.61. The development system according to claim 59, wherein said codegenerator is linked to an integrated development program.
 62. Thedevelopment system according to claim 59, wherein said provider of saidserver-side services is a Java-enabled server.
 63. The developmentsystem according to claim 62, wherein said client is a Java-enabledclient.
 64. The development system according to claim 59, wherein saidmediator program is compiled from Java source code by said codegenerator.
 65. The development system according to claim 59, whereinsaid first messages are smaller than corresponding ones of said secondmessages.
 66. The development system according to claim 59, wherein saidfirst messages each comprise a plurality of said requests.
 67. Thedevelopment system according to claim 59, wherein an input of said codegenerator comprises a predefined template.
 68. The development systemaccording to claim 67, wherein said template comprises Java source code,wherein at least a part of said Java source code is copied by said codegenerator to an output file.
 69. The development system according toclaim 68, wherein said template further comprises a logical directivethat specifies said part of said Java source code.
 70. The developmentsystem according to claim 68, wherein said mediator program is generatedby said code generator responsively to said template.
 71. Thedevelopment system according to claim 59, wherein said second protocolis SOAP.
 72. The development system according to claim 59, wherein saidproxy code comprises proxy classes.
 73. The development system accordingto claim 59, wherein said proxy code comprises a synchronous stub. 74.The development system according to claim 59, wherein said proxy codecomprises an asynchronous stub.
 75. The development system according toclaim 59, wherein said proxy code comprises a grouped stub.
 76. Thedevelopment system according to claim 59, wherein said proxy codecomprises instructions for enablement of HTTP for transport of saidfirst messages.
 77. The development system according to claim 59,wherein said proxy code comprises instructions for enablement of HTTPSfor transport of said first messages.
 78. The development systemaccording to claim 59, wherein said proxy code comprises no more thanone procedure for accessing said server-side services.